ADR-001: TiDB数据库选型决策
背景与问题
松鼠提醒项目需要为亿级用户提供实时位置追踪和提醒服务，核心需求包括：
- 高并发写入：每用户每5秒上报一次状态，峰值QPS预估50万+
- 地理分布式：用户主要分布在香港、新加坡、深圳湾区
- 实时分析：需要同时支持OLTP（事务）和OLAP（分析）查询
- 水平扩展：数据量预计PB级，需要自动分片能力
问题：选择哪种数据库架构能同时满足上述需求？
考虑选项
选项对比表
| 维度 | MySQL分库分表 | PostgreSQL + Citus | TiDB Cloud | Aurora MySQL |
|---|---|---|---|---|
| 自动分片 | ❌ 需手动拆分 | ⚠️ 需配置 | ✅ 原生支持 | ❌ 只读副本 |
| 扩展性 | 复杂，需改代码 | 中等 | 线性扩展 | 垂直扩展有限 |
| MySQL兼容 | ✅ 100% | ❌ 不兼容 | ✅ 协议兼容 | ✅ 100% |
| HTAP能力 | ❌ 需异构同步 | ⚠️ 有限 | ✅ TiFlash列存 | ❌ 需DMS |
| 多地域 | 自建复杂 | 自建复杂 | ✅ 香港+新加坡 | ⚠️ 单区域主从 |
| 运维成本 | 高（2名DBA） | 中（1名DBA） | 低（Serverless） | 中 |
| 成本估算 | ¥50万/年 | ¥35万/年 | ¥25万/年 | ¥40万/年 |
| 团队学习 | 熟悉 | 需学习 | 需学习TiDB | 熟悉 |
各选项详细分析
1. MySQL分库分表（Shardingsphere/Mycat）
- 优点：团队熟悉，生态成熟
- 缺点：
- 分片键设计复杂，热点难以处理
- 分布式事务需要XA，性能损耗大
- 扩容时需要手动rebalance数据
- 跨分片查询性能差
2. PostgreSQL + Citus
- 优点：开源，强大的分析能力
- 缺点：
- 国内生态不如MySQL
- 云厂商支持不如MySQL完善
- 需要自运维Citus协调节点
3. TiDB Cloud（推荐）
- 优点：
- 原生分布式，无需分片键设计
- 香港+新加坡双Region部署
- TiFlash列存引擎支持实时分析
- Serverless按需付费，成本可控
- 与MySQL协议完全兼容
- 缺点：
- 相对较新，社区不如MySQL大
- 某些MySQL特性不完全支持（如存储过程、外键）
4. AWS Aurora MySQL
- 优点：托管服务，稳定性高
- 缺点：
- 本质仍是主从架构，写入无法水平扩展
- 跨区域延迟较高
- 成本较高
决策与理由
最终决策：选择 TiDB Cloud Serverless Tier
决策理由
- 架构契合度 ⭐⭐⭐⭐⭐
- 松鼠提醒的数据天然是时间序列+地理位置的分布，TiDB的分布式事务和TiFlash列存完美匹配
-
无需分片键设计，简化开发
-
成本优势 ⭐⭐⭐⭐⭐
- Serverless按请求计费，冷启动成本低
-
预估年成本25万，比其他方案节省30-50%
-
地理位置 ⭐⭐⭐⭐⭐
- 香港Region延迟<10ms，满足大湾区用户需求
-
新加坡Region覆盖东南亚
-
团队迁移成本 ⭐⭐⭐⭐
- MySQL协议兼容，现有SQL基本无需修改
-
ORM框架（如GORM）直接可用
-
生态支持 ⭐⭐⭐⭐
- PingCAP提供商业支持
- 国内社区活跃，中文文档完善
风险与缓解措施
| 风险 | 影响 | 缓解措施 |
|---|---|---|
| TiDB生态较新，遇到问题解决方案少 | 中 | 1. 购买PingCAP企业支持 2. 建立MySQL迁移回退方案 |
| 某些MySQL特性不支持 | 低 | 1. 代码审查禁止使用存储过程和外键 2. 使用应用层实现约束 |
| 延迟敏感场景性能不如预期 | 中 | 1. PoC阶段进行压测 2. 热点数据使用Redis缓存 |
| 供应商锁定 | 低 | 1. 保持SQL标准语法 2. 抽象数据访问层 |
MySQL回退方案
保留以下回退能力： 1. 数据导出：TiDB Lightning支持全量导出为MySQL格式 2. 应用层兼容：数据访问层使用标准SQL，避免TiDB特有语法 3. 双写机制：关键数据可同时写入TiDB和备用MySQL（成本可控时启用）
实施计划
- Phase 1（1-2周）：TiDB Cloud环境搭建，Schema设计
- Phase 2（2-3周）：数据访问层抽象，代码改造
- Phase 3（1周）：数据迁移，压测验证
- Phase 4（1周）：灰度上线，监控观察
相关文档链接
🐿️ 松鼠提醒项目 | 架构师 @architect-lead | 已批准TiDB Cloud作为核心数据存储方案